﻿ 2 3 Mecanisme de control a concurenţei, comunicare şi sincronizare În practică, aplicaţiile concurente, atât la nivel de sistem de operare, cât şi la nivel de program s-au proiectatşi implementat folosindu-se diverse mecanisme de control al concurenţei Se vor defini, la nivel conceptual, câteva astfel de mecanismeşi se vor analiza relaţiile dintre aceste mecanisme 2 3 1 Semafoare Conceptul de semafor a fost introdus de Dijkstra, pentru a facilita sincronizarea proceselor, prin protejarea secţiunilor critice şi asigurarea accesuluiexclusivla resursele pe care procesele le accesează Secţiunile critice sunt secvenţe de instrucţiuni care pot genera race – conditionşi a căror execuţie de către mai multe procese trebuie controlată Formal, un semafor se poate defini ca o pereche (v(s),c(s)) unde: -v(s) este valorea semaforului- un nr întreg a cărui valoare poate varia pe durata execuţiei diferitelor procese Iniţializabil cu 1 sau 0 (TRUE sau FAlSE); -c(s) o coadă de aşteptare la semafor - conţine referinţe la procesele care la semaforul s Iniţial coada este vidă, iar disciplina cozii depinde aşteaptă de sistemul de operare (LIFO, FIFO, priorităţi, etc ) Fiecărei secţiuni critice trebuie să i se aloce un semafor Semafoare Gestiunea semafoarelor: prin 2 operaţii indivizibile P(s) –este apelată de către procese care doresc să acceseze o regiune critică pt a obţine acces Efect: - dacă v(s) este 1(TRUE), execuţia lui P(s) are ca efect accesul procesului apelant la secţiunea critică şi trecerea semaforului pe zero - dacă v(s) este 0 (False), procesul ce doreşte execuţia lui P(s) aşteaptă V(s) Efect : modificarea valorii semaforului şi trecerea sa din 0 (FALSE) în 1 (TRUE) Ac funcţie se apelează la sfârşitul secţiunii critice şi semnifică eliberarea acesteia pt alte procese IMPLEMENTAREA SEMAFOARELOR: El Hardware ale CPU El A sist de operare Succesiune instrucţ : P(s) regiune critică V(s) Rest procesului Operaţiile P şi V pot fi exprimate în pseudo cod Operaţiile P şi V pot fi exprimate în pseudo cod Dacă procesul execută regiunea critică înseamnă că la intrarea sa în proces avem: v(s)=0 sau mai mare În UNIX -Noţiunea de semafor a fost generalizată prin posibilitatea de a executa mai multe operaţii asupra unui semafor inclusiv incrementare decrementare cu valori diferite de 1 -Se lucreaza cu multimi de semafoare care sunt descrise de structuri de date ce contin o alta structura reprezentind permisiunile proceselor la semafoare, un pointer la primul semafor din set, momentul de timp la care a avut loc ultima operatie asupra setului de semafoare - Accesul unui proces la un set de semafoare este controlat; doar procesele cu anumite caracteristici fiind capabile sa modifice semafoarele Semaforul este un instrument fundamental al concurenţei În UNIX noţiunea de semafor a fost generalizată prin posibilitatea de a executa mai multe operaţii asupra unui semafor inclusiv incrementare decrementare cu valori diferite de 1 Notatie adoptata pentru definirea si atribuirea valorii initiale a unui semafor: primeşte valoarea iniţialăv(s)=x 0 2 3 2 Variabile mutex Variabila mutex (mutual exclusion): - un instrument util pentru protejarea unor resurse partajate, accesate concurent de mai multe thread-uri - sunt folosite, de asemenea, pentru implementarea secţiunilor criticeşi a monitoarelor (notiuni pe care le vom defini în secţiunile imediat următoare) - are două stări posibile: blocată (este proprietatea unui thread) sau neblocată (nu este proprietatea nici unui thread) Un task care vrea să obţină o variabilă mutex blocată de alt task, trebuie să aştepte până când primul o eliberează Operaţiile posibile asupra variabilelor mutex: -iniţializarea (static sau dinamic); -blocarea(pentruobţinerea accesului la resursa protejată); - deblocarea (pentru eliberarea resursei protejate); - distrugerea variabilei mutex Variabile mutex Din punct de vedere conceptual, o variabilă mutex este echivalentă cu un semafor s, care poate lua două valori: 1 pentru starea neblocatăşi 0 pentru starea blocată (Un astfel de semafor se va numi semafor binar) Operaţiile asupra unei variabile mutex m se definesc, cu ajutorul semafoarelor, astfel: • Iniţializare: se defineşte un semafor m astfel încât v(m) = 1 0 • Blocare: (după o eventuală deblocare de către alt thread): P(m) • Deblocare: V(m) • Distrugere: distrugerea semaforului m 2 3 3 Variabile condiţionale Definiţie, caracteristici - Sunt obiecte de sincronizare şi comunicare între task-urile care aşteaptă satisfacerea unei condiţii şi task-ul care o realizează - Au asociate: un predicat-dăcondiţia ce trebuie să se realizeze şi care de obicei implică date partajate; o variabilă mutex - asigură faptul că verificarea condiţieişi intrarea în aşteptare, sau verificarea condi- ţieişi semnalarea îndeplinirii ei să fie exe- cutate ca şi operaţii atomice Operaţiile posibile asupra variabilelor condiţionale sunt: • Iniţializare: care poate fi statică sau dinamică; •Aşteptare(wait): threadul este pus în aşteptare până când i se va semnala din exterior îndeplinirea condiţiei; • Semnalare (notify, broadcast, notifyall): threadul curent anunţă unul dintre thread-urile ce aşteaptă îndeplinirea condiţiei, sau toate thread-urile ce aşteaptă îndeplinirea condiţiei; • Distrugere; 2 3 4 Conceptul de monitor •Un monitor este o construcţie similară cu un tip de date abstract Scopul său principal este de a încapsula variabilele partajateşi operaţiile asupra acestora Astfel, toate secţiunile critice sunt concentrate în această structu- ră la care, la un moment dat, are acces unul singur dintre task-uri Secţiunile critice sunt extrase din task-urile obişnuite şi devin proceduri sau funcţii ale monitorului • In modelul lui Hoare (1974), un monitor poate fi descris ca un obiect care conţine: 1 datele partajate; 2 procedurile care accesează aceste date; 3 o metodă de iniţializare a monitorului; Conceptul de monitor OBS - Fiecare grup de proceduri este controlat de un monitor; - În momentul rulării programului multi-thread, monitorul permite unui singur thread să execute o procedură controlată de el In această situaţie, vom spune că threadul a ocupat monitorul; -Dacă alte thread-uri invocă monitorul în timp ce acesta este ocupat, ele sunt suspendate până când procedura monitor apelată de thread-ul respectiv îşi încheie activitatea, ceea ce coincide cu eliberarea monitorului de către thread Conceptul de monitor Implementări ale conceptului de monitor Pascal Concurent Mesa Java - o variantă de monitor cu ajutorul modificatorului synchronised Monitorul este un concept mai uşor de manevrat decât semaforul Din punct de vedere conceptual, un monitor poate fi descris simplu folosind un singur semafor binar, cu valoarea iniţială 1 Fiecare procedură a monitorului începe cu P(s) şi se încheie cu V(s): 2 3 5 Secţiune şi resursă critică; excludere mutuală •Prinexcludere mutuală a două procese se exprimă faptul că în fiecare moment numai unul dintre procese poate să fie activ •Prinresursă critică este indicată o resursă care poate fi ocupatăşi folosită la un moment dat numai de către un singur proces •Prinsecţiune critică se indică o porţiune de cod care nu poate fi executată la un moment dat decât de un singur task şi care secţiune, odată iniţiată, execuţia ei trebuie să fie terminată fără a fi întreruptă de un alt task OBS -Secţiunile critice trebuie să fie, de regulă, cât mai scurte posibil deoarece toate celelalte task-uri sunt întârziate până la terminarea execuţiei unei asemenea secţiuni critice -Problema secţiunii critice prezintă un interes deosebit, atât din punct de vedere teoretic, câtş i din punct de vedere practic Majoritatea "subtilităţilor" programării concurente se leagă, într-un fel sau altul de ea Secţiune şiresursă critică; excludere mutuală Osecţiune critică bine definită trebuie să îndeplinească următoarele condiţii: 1 la un moment dat, numai un singur proces este în secţiunea critică; orice alt proces solicită accesul la ea, îl va primi numai după ce procesul ocupant a terminat de executat instrucţiunile secţiunii critice; 2 vitezele relative ale proceselor care accesează secţiunea critică sunt necunoscute; 3 oprirea oricărui proces trebuie să aibă loc numai în afara secţiunii critice; 4 nici un proces nu va aştepta indefinit pentru a intra în secţiunea critică Există diverse modele de implementare a secţiunii critice Implicit, toate acestea rezolvă excluderea mutualăşi resursele critice Osecţiune critică trebuie implementată, la fel caşi la monitor, folosind un semafor binar s, cu valoarea iniţială 1 2 3 6 Regiuni critice condiţionale Prin regiune critică condiţională se înţelege o secţiune critică plus o resursă critică plus verificarea unei condiţii înainte de execuţia efectivă •Fiecărei regiuni critice i se asociază o resursă constând din toate variabilele care trebuie protejate în regiune Declararea ei se face astfel: unde r este numele resursei, iar v1 , , vn sunt numele variabilelor de protejat •O regiune critică condiţională se specifică astfel: - unde r este numele unei resurse declarate ca mai sus, B este o expresie booleană, iar S este secvenţa de instrucţiuni corespunzătoare regiunii critice - dacă este prezentă opţiunea when, atunci S este executată numai dacă B este adevărată Descrierea prin semafoare a unei regiuni critice condiţionale este dată în figura 2 10 Pentru descriere sunt necesare două semafoareşi un număr întreg Semaforul sir reţine in coada lui toate procesele care solicită acces la regiune Semaforul exclus asigură accesul exclusiv la anumite secţiuni ale implementării Intregul nr reţine câte procese au cerut acces la regiune, la un moment dat 2 3 7 Conceptul de întâlnire (rendez-vous) Conceptul de întâlnire (rendez-vous) este introdus de limbajul Ada pentru a facilita comunicarea între două task-uri a) Procesul B este gata să transmită informaţiile, dar procesul A nu le-a cerut încă In acest caz, procesul B rămâne în aşteptare până când procesul A i le cere b) Procesul B este gata să transmită informaţiile cerute, iar procesul A cere aceste date In acest caz, se realizează un rendez-vous, cele două procese lucrează sincron până când îşitermină schimbul, după care fiecare îşicontinuă activitatea indepen- dent c) Procesul A a lansat o cerere, dar procesul B nu este în măsură să-i furnizeze informaţiile solicitate In acest caz, A rămâne în aşteptare până la întâlnirea cu B Mecanismul se poate descrie folosind un semafor, s Procesul A execută o operaţie P(s) înainte de punctul de întâlnire, iar procesul B execută o operaţie V(s) înainte de punctul de întâlnire 2 4 Implementări ale mecanismului de excludere reciprocă Modalităţile practice de implementare a mecanismului de excludere reciprocă operează prin: • inhibarea întreruperilor, • excluderea reciprocă prin programare, •instrucţiunea de interschimbare, • semafoare binare, • regiuni critice simple, • monitoare 2 4 1 Inhibarea întreruperilor •Este o soluţie hardware Când un program ajunge într-o secţiune definită critică, se generează o întrerupere care, prin hardware, inhibă celelalte întreruperi (prin mascare), pe durata execuţiei secţiunii critice •Este o metodă simplăşi eficientă, însă presupune o inhibare neselectivă a tuturor întreruperilor ce poate duce la întârzieri semnificative în executarea celorlalte task-urilor 2 4 2 Excluderea reciprocă prin programare Este o metodă software bazată pe ipoteza că accesele individuale la locaţiile de memorie sunt indivizibile Soluţii de implementare software a excluderii reciproce între două task-uri ciclice, fiecare având câte o secţiune critică: 1 - prin utilizarea unei variabile comune speciale pentru protejarea secţiunilor critice, variabilă denumită “poartă”, care poate avea două stări (valori) “deschis”şi, respectiv, “închis” Dacă valoarea variabilei este “închis” înseamnă că unul dintre task-uri se găseşte în secţiunea ei critică; -“deschis” -înseamnă că task-ul poate executa secţiunea sa critică; -simultan “deschis” ambele task-uri iniţiază execuţia secţiunii critice proprii OBS: nu garantează excluderea reciprocă corectă între două task-uri concurente 2 - prin utilizarea unei variabile comune speciale pentru a dirija cele două task-uri concurente în momentul în care ele încearcă să execute secţiunile lor critice Astfel, o variabilă întreagă, numit “comutator”, valoarea 1 = task-ul 1 poate executa secţiunea sa critică valoarea 2 = task-ul 2 poate executa secţiunea sa critică se garantează excluderea reciprocă a celor două task-uri concurente OBS: impune o execuţie alternantă obligatorie a secţiunilor critice ale celor două task-uri (tot timpul în ordinea 1,2,1,2, ) Excluderea reciprocă prin programare 3 - Prevederea pentru fiecare task în parte a unei variabile proprii locale care poate avea doar valorile “interior” şi respectiv “exterior” -“interior” = task-ul respectiv doreşte să execute secţiunea sa critică; -“exterior” = task-ul respectiv este în afara secţiunii sale critice; - fiecare dintre task-urile concurente poate examina valoarea variabilei corespun- zătoare task-ului concurent înainte de a trece la execuţia secţiunii critice -nu există nici o variabilă manipulată în comun; OBS - asignarea simultană a valorii “interior” variabilelor proprii = buclă infinită 4 - task-ul care detectează faptul că ambele task-uri concurente încearcă să treacă la execuţia secţiunilor critice proprii, va modifica valoarea variabilei locale de control = atunci bucla infinită va fi evitată OBS –Situaţie critică dacă cele două task-uri derulează exact în acelaşiritm(doi abonaţi telefonici se apelează reciproc în acelaşi moment de timp) Excluderea reciprocă prin programare 5-Combinarea ultimelor două propuneri Variabilă proprie, care indică dorinţa de a trece la execuţia secţiunii critice iar în cazul în care ambele task-uri doresc simultan acest lucru Se utilizează o variabilă întreagă auxiliară pentru rezolvarea acestui conflict Fiecare task acţionează doar asupra variabilei celuilalt task concurent doar dacă variabila proprie are valoarea “interior” El va trece la executarea secţiunii critice proprii numai dacă task-ul concurent este în afara secţiunii sale critice Variabila întreagă “comutator” este folosită pentru a rezolva conflictele între task-urile concurente permiţând task-ului, al cărui număr este în acel moment atribuit ca valoarea variabilei “comutator”, să intreînexecuţia secţiunii sale critice La ieşirea din secţiunea critică, task-ul va modifica valoarea variabilei “comutator”şi celălalt task va putea, astfel, să treacă la execuţia secţiunii sale critice Excluderea reciprocă prin programare Condiţii generale pentru realizarea corectă a excluderii reciproce a task-urilor concurente: • La un moment dat, cel mult un singur task se poate găsi în secţiunea sa critică; • Oprirea unui task în afara secţiunii sale critice nu trebuie să afecteze celelalte task-uri; • Nu se poate face nici o ipoteză asupra vitezei relative de desfăşurare a task-urilor; • Task-urile ce sunt pe cale de a trece la execuţia secţiunilor lor critice, nu trebuie să se blocheze reciproc la infinit 2 4 3 Instrucţiunea de interschimbare Metodele anterioare de rezolvare prin software a problemei excluderii reciproce, presupun doar indivizibilitatea acceselor singulare la locaţiile de memorie ????? S-ar putea executa 2 operatii anumite (interschimbarea continutului unei locatii de memorie cu cel al unui registru local) fara a fi intrerupte 2 4 3 Instrucţiunea de interschimbare Soluţia: Variabila globală “excludere” este iniţializată cu o valoare egală cu unitatea Înainte de a se executa secţiunea critică, task-ul trebuie să obţină valoarea unităţii memorate de variabila “excludere”şi să stabilească valoarea zero acestei variabile, ambele acţiuni printr-o singură operaţie indivizibilă La sfârşitul acţiunii critice, task-ul va returna valoarea unitate variabilei “excludere” Deoarece există o singură valoare unitate în sistem, cel mult un singur task îl poate obţine Dacă un task nu este capabil să treacă la execuţia secţiunii sale critice, el va trebui să stea într-o buclă de aşteptare (în mod continuu) Când valoarea unitate a variabilei “excludere” este eliberată, una singură dintre buclele de aşteptare va putea să o folosească OBS Metoda este acceptabilă dacă există o solicitare moderată a iunile critice sunt scurte resurselorşi dacă secţ 2 4 4 Semafoare binare Caracteristică comună a metodelor anterioare: -Dcă un task doreşte să execute o secţiune a sa criticăşi nu i se permite acest lucru, atunci el pierde dreptul de a utiliza CPU - Este preferabil ca un asemenea task să fie trecut în starea de “blocat” urmând să fie adus în starea “gata de execuţie” în momentul în care este posibil să treacă la execuţia secţiunii sale critice Semafoare binare (booleene sau variabile mutex) 2 4 4 Semafoare binare OPERARE: 1 Fiecărei secţiuni critice i se asociază un semafor (iniţial având valoarea 1) iar task-ul care doreşte să execute secţiunea sa critică, va efectua o operaţie P; task-ului i se va permite execuţia secţiunii sale critice numai dacă valoarea actualizată (decrementată) a semaforului are valoarea zero În caz contrar, task-ul este trecut în starea “blocat” 2 La ieşirea din secţiunea critică, task-ul va efectua o operaţie de tip V care va provoca incrementarea cu 1 a valorii variabilei semafor; dacă există alte task-uri blocate, unul dintre aceste task-uri va putea trece la executarea secţiunii sale critice Deci, un task va rămâne blocat până când un alt task îi va indica posibilitatea să continue Semafoare binare Operaţiile P şi V sunt indivizibileşi un singur task poate executa la un moment dat una dintre ele asupra aceluiaşi semafor Operaţiile P şi V asupra semafoarelor se pot implementaşi prin hardware dar, de regulă, ele sunt implementate prin software, fiind protejate prin inhibarea întreruperilor Pentru a evita aşteptarea, prin buclare, se foloseşte de regulă un şir de aşteptare în care se insereazăşi se extrag task-urile ce se executau în momentul inhibării întreruperilor Dezavantajul major al utilizării semafoarelor este legat de necesitatea unei programări foarte atente; dacă, de exemplu, din neatenţie se scrie o operaţie primitivă P în loc de V, atunci task-urile se vor bloca reciproc la infinit 2 4 5 Regiuni critice simple Pentru a uşura programarea corectă a semafoarelor este posibil să se utilizezeşi o construcţie de limbaj specifică limbajelor de programare de nivel înalt, cum este, de exemplu, regiunea critică simplă propusă de Hoare: Permite ca instrucţiunile critice S să opereze asupra variabilei comune R Compilatorul respectiv va traduce această construcţie în instrucţiuni de program Această construcţie evită necesitatea de a încadra cu operaţii P() şi V() toate secţiunile criticeşi elimină necesitatea verificării lor de la începutul şi sfârşitul secţiunilor critice Compilatorului verifică totodată faptul că variabilele comune sunt utiliza- te doar în interiorul regiunii critice, actualizarea valorilor variabilelor co- mune fiind astfel protejată 2 4 6 Monitoare Dacă un task doreşte să execute secţiunea sa critică va face apel la pro- cedura corespunzătoare a monitorului; Condiţii de lucru: - unul singur dintre task-uri se admite la un moment dat să se bucure de serviciile monitorului; - toate celelalte apeluri la monitor aştepaptă eliberarea monitorului; - într-un monitor asupra variabilelor partajate nu se pot executa decât operaţii "cunoscute" (declarate o dată cu definirea monitorului) pentru care se asigură în mod automat condiţiile de excludere mutuală; - nu există posibilitatea accesului din exterior la datele locale monitorului decât prin intermediul operaţiilor; - din acest motiv nu pot să apară erori de sincronizare; Monitoare În programarea cu monitoare se consideră că un program conţine două tipuri de module: - procese active - procese pasive Toate variabilele partajate sunt variabile locale monitoarelor Interacţiunea dintre procese are loc numai prin intermediul monitoarelor Un monitor operează asupra a trei tipuri de variabile: - variabile permanente - sunt de fapt variabilele partajate Aceste variabile îşipăstrează valoarea între apelurile operaţiilor asigurate de monitor Iniţializarea acestor variabile se face la crearea monitorului - variabile locale - sunt variabile utilizate pentru realizarea operaţiilor Au acelaşi tip de proprietăţi ca al variabilelor locale în proceduri - parametrii de apel - sunt parametrii operaţiilor realizate de către monitor Monitoare Trecerea unui proces printr-un monitor trebuie să dureze cât mai puţin Ce se întâmpla însă dacă un proces care începe execuţia unei operaţii dintr-un monitor descoperă că trebuie să se blocheze în aşteptarea unui eveniment extern ? Abordări posibile -Se poate interzice apariţia unor astfel de situaţii; -Dacă un proces se blochează (este în aşteptarea unui eveniment) în timp ce se află în execuţia unei operaţii dintr-un monitor atunci un alt proces poa- te să fie lăsat sa utilizeze monitorul Implicaţii: să existe o "evidenţă" a proceselor care aşteaptă apariţia unui eveniment Pentru a asigura semnalizarea blocării în aşteptarea unui eveniment se utilizează variabile condiţie Monitoare-variabile condiţie Variabila condiţie=variabilă partajată, asupra căreia se pot executa două tipuri de operaţii primitive (atomice): - wait (delay) : produce blocarea procesului care o invocă; - signal (resume): anunţă posibilitatea deblocării unuia dintre procesele care a executat operaţia wait pentru variabila respectivă; OBS!!!- Atunci când un proces este blocat ca urmare a execuţiei unei operaţii wait în corpul unei operaţii dintr-un monitor, alte procese pot să utilizeze monitorul -Operaţiile wait şi signal par să "semene" cu operaţiile P şi V - Deosebire importantă Operaţia signal nu are nici un efect dacă nu exista un proces care aşteaptă (ceea ce nu este cazul cu operaţia V care incrementează valoarea semaforului) -Operaţia wait blochează întotdeauna procesul care o execută 2 5 Sincronizarea explicită Se consideră situaţiile în care task-urile concurente doresc să coopereze între ele fiind astfel, într-un fel, interesate de desfăşurarea celorlalte task-uri Task-urile continuă să se concureze pentru a obţine dreptul de a intra în execuţia secţiunii lor critice Odată obţinut acest drept, acţiunea task-ului în timpul execuţiei secţiunii critice poate conduce la realizarea unei condiţii care, anterior, determinase suspendarea (sau întârzierea) execuţieiunuialttask REZULTĂ: -necesitatea existenţei unei metode care să permită unui task să indice (să semnaleze) că un anumit eveniment a avut loc sau să aştepte până când are loc un anumit eveniment - asigurarea unor forme de cooperare între task-uri, spre avantajul lor reci- proc; SINCRONIZARE Două programe se consideră sincronizate nu numai dacă sunt lansate în execuţie concomitent ci şi dacă se pot stabili relaţii reciproce temporale predictibile între anumite momente ale desfăşurării lor Sincronizarea explicită Sensul general al sincronizării este cel de coordonare în timp, de corelare, presupunând o relaţie reciprocă între task-uri, care au un caracter temporal şi stabil Noţiunea de sincronizare s-a extinsşi mai mult, incluzândşi forma de sincronizare cu timpul absolut sau cel real (înţelegând prin aceasta că un anumit task este lansat în execuţie în fiecare zi la o oră fixă sau ciclic, de exemplu, din oră în oră) Sincronizarea trebuie să permită activarea şi respectiv, inhibarea desfăşu- rării unor programe (task-uri) atât prin cereri iniţiate de alte task-uri câtşi prin comenzi ale utilizatorilor, introduse de la terminale Momentele de timp în care se iniţiază aceste acţiuni sunt momentele de sincronizare efectivă Rezultă Sunt necesare funcţii referitoare la “evenimente”, în sensul general al cuvântului, şi anume “aşteptarea” până la producerea evenimentului specificatşi “anunţarea” faptului că acesta s-a produs funcţii mai complexe: aşteptarea primului eveniment dintr-o mulţime precizată de evenimente; aşteptareaşi tratarea selectivă a mai multor evenimente într-o ordine eventual diferită de cea a apariţiei lor; Sincronizarea explicită Metodeleşi mecanismele folosite pentru realizarea sincronizării programe- lor sau task-urilor concurente se deosebesc sub mai multe aspecte: - natura sincronizării: sincronizare între programe sau task-uri sau sincro- nizare cu timpul; - momentul sincronizării: cu începutul unui program, cu sfârşitul unui program sau cu un“punct” (moment) oarecare din interiorul programului; - implementarea sincronizării: prin facilităţi specifice ale limbajelor de pro- gramare (şi ale compilatoarelor asociate), ale limbajului de comandă sau prin facilităţi (servicii) asigurate de un monitor Principalele tehnicişi metode de implementare a sincronizării dintre task-uri concurente sunt prin: 2 5 1 Semafoare generale Un semafor general este o variabilă întreagă, ce poate lua doar valori pozitiveşi singurele operaţii ce se pot efectua asupra lui sunt operaţiile primitive P şi V Dacă semaforul are valoarea zero, un program (task) ce încearcă să efectueze o operaţie P asupra acestuia va fi suspendat (blocat) şiva aştepta până când un alt program va efectua asupra aceluiaşi semafor o operaţie V Modul de utilizare a semafoarelor generale Exemplu:mai multe programe sau task-uri denumite “producătoare”, doresc să comunice o serie de date altor programe sau task-uri concurente, denumiteşi “consumatoare” sau receptoare Necesar:- o zonă de memorie tampon, de capacitate evident limitată, în care producătorii vor depune datele lorşi din care consumatorii le vor extrage când acestea devin disponibile - programele trebuiesc evident sincronizate, astfel încât produ- cătorii să nu depună date noi în zona tampon când aceasta este plină, iar consumatorii să nu extragă date din zona tampon când aceasta este goală Rezultă: înterpătrundere a mecanismelor de sincronizare cu cele de comunicare inter-programe (inter-proces) concurente Sincronizarea necesară între programe se poate realiza în acest caz folosind semafoare generale care să reflecte condiţiile posibile de aşteptare (condiţia de “tampon plin” respectiv “tampon gol”) Pentru a evita suprascrierile sau săriturile peste anumite date din zona tampon, aceste operaţii trebuiesc efectuate prin excludere reciprocă În acest scop, după cum s-a văzut, se poate introduce şi un semafor binar Exemplu Dacă se foloseşte, un semafor general “Plin” pentru a reprezenta numărul de locaţii încărcate (pline) ale zonei tampon, atunci un consumator va trebui întârziat dacă Plin = 0 Dacă un task producător va efectua o operaţie V asupra semaforului “Plin”, după ce a plasat o informaţie în zona tampon, un task-consumator va fi “servit” în urma efectuării unei operaţii P (va avea acces la tampon şi va putea “consuma” informaţia anterior introdusă) În mod similar, un al doilea semafor general “Gol”, poate fi folosit pentru a întârzia după necesităţi task-urile producător Concluzii În general, dacă un task doreşte să aştepte până ce se realizează o anumită condiţie, acestei condiţii de aşteptare i se asociază un semafor şi orice task ce ar putea provoca realizarea condiţiei trebuie să aibă responsabilitatea efectuăriiuneioperaţii V asupra acestui semafor Programatorul va trebui să introducă în fiecare task instrucţiuni de sincronizare cu celelalte task-uri, ceea ce presupune o atenţ ie specială de lucru cu semafoarele generale Dacă mai multe task-uri consumator aşteaptă, ele vor trebui planificate într-un mod neutru sau după unele criterii de prioritate ale task-urilor consumator 2 5 2 Regiuni critice condiţionale Este o structură de programare de forma : unde B este o expresie booleană iar S este o secţiune critică ce operează asupra variabilei comune R Aceastăconstrucţie specificăfaptul căsecţiunea critică de program S trebuie executată doar dacă condiţia B este respectată 2 5 3 Variabile de condiţie - dată ce poate fi utilizată doar în cadrul unui monitor - sunt folosite pentru a identificaşirul de task-uri în aşteptare ce sunt manipulate prin operaţiile “aşteptare” şi “semnalare” Operaţia “aşteptare” dezactivează task-ul şi îl trece într-unşir de aşteptare asociat variabilei de condiţie respective, anulând excluderea reciprocă care ar fi interzis ca un alt task să obţină serviciile monitorului Operaţia “semnalare” va produce reactivarea primului task dinşirul de aşteptare, asociat variabilei de condiţ ie respective Sincronizarea explicită Task-ul care efectuează o operaţie “semnalare” şi provoacă reactivarea unui alt task (trecut anterior în aşteptare) va fi, la rândul său, suspendat până în momentul în care task-ul activat va ieşi din monitor sau va executa o operaţie “aşteptare” OBS!!! Prin detalierea specifică a condiţiilor în care task-urile pot trece în aşteptare şi, respectiv, pot fi reactivate se poate realiza mai simplu şi mai explicit planificarea task-urilor decât în cazul regiunilor critice condiţionale (unde erau nevoie evaluări repetate ale condiţiilor) şi fiecareşir de aşteptare asociat variabilei de condiţie este tratat după strategia “primul - venit, primul - servit” de fiecare dată când se execută o operaţie “semnalare” asupra variabilei de condiţie respective 2 5 4 Sincronizare prin comunicare Comunicareaşi sincronizarea sunt în realitate doar faţete ale aceluiaşi fenomen Programele comunică între ele nu numai pentru a-şi comunica informaţii sub formă de mesaje ci şi pentru a se sincroniza REZULTĂ Un semnal de sincronizare poate fi consideratşi el că este un mesaj fără conţinut ce se transmite între programe Cum se realizează acest lucru? a)Procese secvenţiale comunicante Rendez-vous simetric task-ul A: o comandă de emitere mesaj→ SUSPENDARE ← task-ul B:o comandă de recepţie de mesaj; task-ul B: o comandă de recepţie de mesaj→ SUSPENDARE ← task-ul A: o comandă de emisie de mesaj; task-uri sincronizate→ datele (mesajul) sunt transferate b) Procese distribuite Rendez-vous asimetric Comunicareaşi sincronizarea între programele concurente se realizează în acest caz similar cu apelarea prin nume de către programul emiţător a unei proceduri incluse în programul receptor, lista cu parametrii asociaţi acestui apel fiind folosită ca un “canal” de comunicare pentru transmiterea de date între cele două programe Doar programul apelant trebuie să cunoască numele programului apelat, nu şi invers Implementare Pentru a putea provoca sincronizarea prin rendez-vous a celor două programe, în programul apelat vor trebui inserate “comenzi de acceptare”, care vor avea forma unor proceduri de intrare apelabile de către programele apelante (task-ul apelat este suspendat în aceste puncte de program) DEZAVANTAJE Tipul de rendez-vous este unul asimetric Aceste forme de rendez-vous nu sunt suficient de adecvate pentru progra- marea aplicaţiilor reale Sincronizarea mult prea strânsă a task-urilor împiedică orice operare asin- cronă a programelor şiastfelinhibă avantajele potenţiale ale unui paralelism dezvoltat Procese distribuite Rendez-vous asimetric Eliminarea dezavantajelor: Introducerea posibilităţii de selectare nedeterministă a comenzilor de acceptare Este vorba despre un mecanism pe baza căruia un program receptor poate evita executarea unei comenzi de acceptare şisă fie suspendat După necesităţi, se pot introduce condiţii suplimentare de execuţie a comenzii de selectare După cum vom constata, există şi mecanisme mixte, care au atât caracter sincron, câtşi caracter asincron 